feat(network)!: add bounded service sessions and request resources - #943

ZakuraHeaderSyncDriverStartup::block_range_source is declared as Arc<dyn super::BlockRangeSource> in the changed handler. From zakura::handler, that path must resolve to crate::zakura::BlockRangeSource. No trait, struct, type alias, or re-export with that name exists anywhere in the repository; the field declaration is the only occurrence. Rust must resolve the type while compiling the library even if no runtime path constructs the struct. The zakura-network crate therefore fails to compile.

The diff makes block_range_source a required field of ZakuraHeaderSyncDriverStartup. The repository's sole production struct literal initializes all pre-existing members but omits this new field. It has neither a struct-update expression nor a Default implementation that could provide the value. Once the missing BlockRangeSource type is added, Rust will independently reject this constructor with a missing-field error. The production startup adapter therefore remains uncompilable even after the first name-resolution error is fixed.

stream_kind_label now matches on crate::zakura::ZAKURA_STREAM_BLOCK_REQUESTS. No constant with that name is declared or re-exported anywhere in the repository; the changed match arm is its only occurrence. The implemented native block protocol defines ZAKURA_STREAM_BLOCK_SYNC instead. Rust must resolve every constant path used in a match pattern at compile time. This unresolved symbol prevents the zakura-network library from compiling.

An authenticated peer can keep one connection's reactor unavailable by repeatedly opening a negotiated ordered-pair stream, supplying the ordinary prelude slowly, and withholding the eight-byte pair identifier. serve_connection awaits admit_bi_stream directly inside the sole connection.accept_bi() select branch, so no other reactor branch is polled until peer-paced setup completes. The ordinary prelude's fixed and frame-cap portions each get a separate prelude_timeout, and the new pair identifier gets a third full timeout; under defaults, one stream can occupy the reactor for almost nine seconds. After reset, a prequeued stream can repeat the sequence. The stream-open bucket does not stop this because it refills while the reactor is blocked and the attacker consumes far fewer than the default 32 tokens per second.

For a finite-capacity ordered-pair service, an authenticated peer can occupy a service slot without supplying a usable stream half. admit_bi_stream calls reserve_or_share, which invokes reserve_ordered_session, before reading the peer-controlled eight-byte pair identifier. Withholding those bytes retains the resource owner for the full timeout; supplying the ID retains it in PendingPair until the companion deadline. Once released, a prequeued offer can immediately reacquire the slot. The default three-second setup timeout is far slower than the 32-per-second open-token refill, so the general open limiter never imposes a meaningful cooldown.

The changed regression test constructs the real BlockSyncService, reads streams()[0], and then unconditionally reads streams()[1]. Production BlockSyncService::streams returns block_sync_streams(), which is backed by a one-element [Stream; 1]. The test therefore panics on an out-of-bounds slice index before reaching its registry assertions or network setup. This remains a deterministic test failure after the separately reported undefined stream constant is corrected.

The changed test expects the block-request role to declare a nine-byte type-2 payload limit, but production BlockSyncService does not override Service::message_payload_limits. The registry therefore receives the trait default empty slice. read_frame_with_types only tightens the stream cap when a matching entry exists; with no entry it allocates and reads the full peer-declared payload up to the approximately 3 MiB block-sync stream cap. A type-2 frame can thus carry a valid nine-byte GetBlocks prefix plus megabytes of padding, all of which are allocated and read before the codec rejects trailing data.

The changed handler implements generic paired setup and pair-local write policies, and its new production-facing test assumes block sync has data and request roles. Actual BlockSyncService still declares only stream kind 6 and does not override ordered_stream_pair, so registry lookup always returns None. The handler consequently invokes spawn_single, creates no companion role, and runs block sync under OrderedWritePolicy::Standalone. The custom PairService tests exercise only synthetic generic machinery and do not activate it for production block sync.

The built-in legacy request service inherits empty message_payload_limits and no message_types allowlist while its request/response stream accepts frames up to the 1 MiB control-frame cap. A remote Ping header can therefore declare almost 1 MiB of payload, which read_frame_with_types allocates before LegacyRequestFrame::decode_frame can enforce that Ping payloads are empty. By sending all but the final byte, the peer keeps each allocation live until the long payload timeout. The open limiter still permits enough concurrent streams to repeat this up to the per-connection stream ceiling.

read_frame_with_types does not enforce one deadline after the first frame byte, despite its documented contract. It gives the remaining seven header bytes a full read_timeout, then read_frame_payload starts a second full timeout after parsing and allocation. One-shot request streams also receive a separate full timeout while waiting for the first byte. A peer can make progress just before each boundary and multiply the intended per-frame lifetime.

The new Service::message_types contract promises pre-allocation rejection of message types not accepted on a stream role. Admission stores the service's allowlist in StreamWorkerContext, but request_stream_worker calls the read_frame wrapper, which always passes None to read_frame_with_types. No later transport or registry check restores the allowlist. Custom request/response services therefore receive types they explicitly excluded through the new API.

An authenticated peer controls StreamPrelude.max_frame_bytes, and admission copies its minimum directly into outbound_frame_cap without checking that it can carry a frame header or mandatory protocol message. The peer can establish healthy sibling services, then open discovery or a paired role with a cap such as one byte. Discovery immediately queues non-empty hello/query frames; encoding against that cap fails deterministically. The worker treats this peer-induced local encode failure as a generic ordered_write_error and cancels the shared connection token.

OrderedSessionState.remote_session_id is cleared only after the old worker fully ends and its asynchronous OrderedSessionExit is selected by the connection reactor. A remote endpoint entitled to reopen an ordered service can close/reset the old stream or pair and immediately open the replacement. QUIC acceptance of the new stream is not ordered after old-worker teardown, and a pair delays its single exit until both role workers end. If the replacement is admitted first, the stale remote ID causes the handler to classify the valid next generation as a duplicate and cancel the entire connection.

A peer can negotiate max_open_streams = 2 and establish a two-stream ordered pair, consuming both permits in the connection-wide application semaphore. It can then continuously open additional QUIC bidirectional streams. Each is rejected at the semaphore check before open_limiter.try_take, so none consumes stream-open budget. Because the reactor uses a biased select with accept_bi before the sibling outbound-work branch, a maintained backlog of these uncharged streams repeatedly wins selection. The QUIC transport's remote stream allowance is configured from the larger local hard maximum rather than the lower negotiated application limit.

The discovery test assigns the complete result of BlockSyncService::new_for_test(...) to block_sync and wraps that value in Arc. The constructor returns (Self, mpsc::Receiver<BlockSyncEvent>), so this creates Arc<(BlockSyncService, mpsc::Receiver<BlockSyncEvent>)> rather than Arc<BlockSyncService>. Consequently, the value cannot satisfy the Arc<dyn Service> expected by set_connection_owners. The tuple-backed Arc also does not expose BlockSyncService methods such as add_peer, causing an additional compilation error. Destructure the constructor result first, retain or explicitly ignore the event receiver as appropriate, and wrap only the returned service in Arc.